Companies today are tasked with implementing solutions for many types of integration challenges within their respective enterprises. Many of these challenges involve issues of application integration (e.g., integration among and/or between software applications and/or other systems) and fall into common patterns.
For example, a first area relates to propagation of similar business objects from one system to multiple other systems, such as, for example, in an order status change or a product price change. A second area relates to synchronization of similar business objects between two or more systems to obtain a single view, such as, for example, a real-time synchronization of customer, product registration, product order, and product SKU information among several applications. This is the most common issue requiring an integration solution. In a one-way synchronization, there generally is one system (e.g., resource) that acts as a data source and one or more resources that are targets of the synchronization. In a two-way synchronization, every resource often is both a potential source and target of a synchronization. There generally is not a single resource that acts as the primary data resource. Thus, a change to any resource should be reflected in all other resources. A third area involves information joined from multiple sources into a common destination system, such as, for example, communicating pharmacy customer records and prescription transactions and website data into a central application and database.
Various tools have been provided that enable a user to design and deploy solutions that address these challenges using, for example, the publish-and-subscribe model or one of its variants. The publish-and-subscribe model is a specific type of message-based solution in which messages are exchanged anonymously through a message broker. Applications that produce information that needs to be shared make this information available in specific types of recognizable documents that they publish to the message broker. Applications that require information subscribe to the document types they need.
At run time, the message broker receives documents from publishers and then distributes the documents to subscribers. The subscribing application processes or performs work using the document and may or may not send a response to the publishing application.
In a typical system, an integration server or applications running on an integration server publish documents to a broker. The broker then routes the documents to subscribers located on other integration servers. The integration server and the broker share a fast, efficient process for exchanging documents across the entire system.
Although such techniques have been successful in providing solutions to the above-described challenge areas, further enhancements are still possible. For example, the integration server (IS) “Trigger Subsystem” provides a rich infrastructure for message processing (e.g., asynchronous message processing). However, this functionality is only available for messaging over a proprietary (e.g., broker) messaging protocol. Thus, users currently have to make a difficult design decision, choosing between either a feature-rich proprietary protocol, or a standards-based interoperable messaging protocol (e.g., JMS).
One approach to solving this problem has involved the use of a JMS adapter provided to an integration server. Thus, both a proprietary “trigger subsystem” (provided by the integration server for proprietary messaging) and a separate JMS adapter were provided to the integration server.
Unfortunately, this approach is somewhat incomplete. In particular, despite the availability of a JMS adapter for standards-based interoperable messaging, the “trigger subsystem” capabilities could not be fully used in connection with JMS. That is, users who want the extended capabilities of the “trigger subsystem” while using the JMS adapter would have to custom-implement those capabilities in their applications for every new application. This often imposes significant configuration and programming requirements and has led to a plethora of non-standardized implementations of the same and/or similar functionality. This problem is further exacerbated, as JMS is still in the process of being standardized for use in the in web-services context. In essence, this means that if capabilities comparable to those of the proprietary broker were required, they would have to be implemented in the application services layer time and time again. Even where such approaches have been implemented, they have not been standardized, e.g., because enterprises are different in terms of their organizations, processes, requirements, infrastructure, etc.
Thus, a problem remains in that there is not a single means to couple the current “trigger subsystem” and all of its capabilities with standards-based messaging (e.g., via JMS). Accordingly, there remains a tradeoff between a feature-rich proprietary protocol on the one hand, and a standards-based interoperable messaging protocol (e.g., JMS) on the other.
Thus, it will be appreciated that there is a need in the art for improved techniques for providing application integration solutions in one or more of the above-noted and/or other areas.
One aspect of certain example embodiments of this invention relates to a messaging layer that provides a rich feature set for addressing application integration challenges that is accessible through both proprietary and open messaging constructs existing outside of the application layer. In certain example embodiments, such messaging constructs may be in the form of “triggers,” and such triggers may enable a publish-and-subscribe type solution to such application integration challenges in certain example embodiments. The triggers of certain example embodiments may be JMS triggers.
Another aspect of certain example embodiments relates to parallel subsystems being accessible through a common trigger subsystem provided as value-added layer above the respective trigger subsystems.
Still another aspect of certain example embodiments relates to substantially fully embedding JMS as a peer to the proprietary messaging protocol in the integration server trigger subsystem so that all or substantially all existing capabilities would be JMS-enabled.
A further aspect of certain example embodiments relates to the use of a messaging layer that enables JMS messaging without the use of a special adapter provided to an integration server. Furthermore, in certain example embodiments, such a messaging layer may make it possible to avoid making any changes to the JMS trigger itself and/or may reduce the need for custom programming and/or implementation at the application service level in certain example cases.
In certain example embodiments, a trigger subsystem for use with an application integration system is provided. At least one proprietary trigger subsystem is embedded in the trigger subsystem. At least one standards-based trigger subsystem is substantially fully embedded in the trigger subsystem. Common trigger facilities are provided for the at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem. The at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem are provided as parallel subsystems. Each said proprietary trigger subsystem and each said standards-based trigger subsystem is configured to access a corresponding trigger layer. Each said trigger layer is configured to provide triggers in a format associated with the respective trigger layer. The triggers include instructions for causing a process to be executed in or by the application integration system or a component thereof.
In certain other example embodiments, there is provided a messaging layer for use across an integration server or an integration server instance provided as a component in an application integration system. A trigger subsystem includes at least one proprietary trigger subsystem embedded therein, at least one standards-based trigger subsystem substantially fully embedded therein, and common trigger facilities for the at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem. The at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem are provided as parallel subsystems in the trigger subsystem. A plurality of parallel trigger layers is respectively provided for each said proprietary trigger subsystem and each said standards-based trigger subsystem. A plurality of messaging API layers is respectively provided for each said proprietary trigger subsystem and each said standards-based trigger subsystem. Each said trigger layer is configured to provide triggers in a format associated with the respective trigger layer. The triggers include instructions for causing a process to be executed in or by the application integration system or a component thereof.
According to certain example embodiments, a method of configuring an application integration system is provided. There is provided a messaging layer for use across an integration server or an integration server instance provided as a component in the application integration system. In the messaging layer, a trigger subsystem is included. At least one proprietary trigger subsystem is embedded in the trigger subsystem. At least one standards-based trigger subsystem is substantially fully embedded in the trigger subsystem. The trigger subsystem is configured to provide common trigger facilities for the at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem. A plurality of trigger layers is respectively provided for each said proprietary trigger subsystem and each said standards-based trigger subsystem. A plurality of messaging API layers is respectively provided for each said proprietary trigger subsystem and each said standards-based trigger subsystem. The at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem are provided as parallel subsystems in the trigger subsystem. Each said trigger layer is configured to provide triggers in a format associated with the respective trigger layer. The triggers include instructions for causing a process to be executed in or by the application integration system or a component thereof.
According to certain other example embodiments, there is provided a method of operating an application integration system based on a publish-and-subscribe model or a variant of the publish-and-subscribe model. There is provided a messaging layer for use across an integration server or an integration server instance provided as a component in the application integration system. The messaging layer includes a trigger subsystem included therein, with the trigger subsystem comprising at least one proprietary trigger subsystem embedded therein and at least one standards-based trigger subsystem substantially fully embedded therein, and with the trigger subsystem being configured to provide common trigger facilities for the at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem. Also included in the messaging layer is a plurality of trigger layers respectively provided for each said proprietary trigger subsystem and each said standards-based trigger subsystem, with each said trigger layer being configured to provide triggers in a format associated with the respective trigger layer. In the triggers, instructions are included for establishing subscriptions to publishable document types and for specifying one or more services to process documents received by the subscriptions. One or more documents are published to one or more subscribers in dependence on the instructions included in the corresponding trigger(s). Each said document is processed in dependence on the instructions included in the corresponding trigger(s). The at least one proprietary trigger subsystem and the at least one standards-based trigger subsystem are provided as parallel subsystems in the trigger subsystem.
These aspects and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.